fix: override user info on GitHub sign-in to self-heal stale-emailed accounts - #61

Status update: existing duplicates are fixed in production; this PR is now preventative

The five existing affected users have been repaired directly in the planner's production database today — a merge of their duplicate members into their real accounts. Each merge:

• moved the duplicate's codebar auth_service onto the real member,
• removed the now-empty duplicate member row,
• cleaned up redundant subscriptions / workshop & event invitations.

Verified post-apply: no duplicate members remain and no orphaned references to the deleted rows.

A side note surfaced during the cleanup: the local codebar_dump was staler than production (a redundant member and one extra invitation were present only in production), which a first run of the script caught by rolling back on a unique index — the transaction's atomicity left production untouched, and the corrected script then applied cleanly.

Because the merges move each user's codebar / <stored-email> credential onto their real member, the planner's existing AuthService.find_by(provider, uid) now resolves to the correct account on their next sign-in. So the existing users are fixed irrespective of this PR.

That makes this change preventative rather than remedial:

• it stops overrideUserInfoOnSignIn-style drift by re-deriving the stored email from the provider on every sign-in, so a user's email can't silently fall out of step again;
• it protects any user who wasn't among today's five from the same class of bug going forward;
• it reduces the need for future manual merges.

Still worth shipping, but it is hardening — it is not what unblocks the current five.